System and method for programmatic device connectivity

ABSTRACT

A system and method for programmatically managing device connectivity to a network that includes provisioning connectivity devices with an account of a communication platform, where for a set of the connectivity devices, provisioning includes uniquely associating network operating identifiers of each of the connectivity devices with a corresponding programmatic device resource in the communication platform, setting communication metering properties in a programmatic connectivity plan resource in the communication platform and associating the connectivity plan resource to at least a subset of the device resources of the connectivity devices, and activating network communication status of the connectivity devices; servicing communications from the connectivity devices; and programmatically managing the communications from the connectivity devices through at least the device resources and the connectivity plan resources.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims the benefit of U.S.patent application Ser. No. 16/042,823, filed on 23 Jul. 2018, which isa continuation of and claims the benefit of U.S. patent application Ser.No. 15/602,809, filed on 23 May 2017, which claims the benefit of U.S.Provisional Application No. 62/340,333, filed on 23 May 2016, both ofwhich are incorporated herein by reference.

TECHNICAL FIELD

This invention relates generally to the communication field, and morespecifically to a new and useful system and method for programmaticdevice connectivity in the communication field.

BACKGROUND

More and more devices are becoming network enabled. Personal computingdevices such as phones, tablets, watches, and laptops may be accompaniedwith SIM cards or other mechanisms to connect to a carrier network.However, such connectivity is not limited to personal computers. Theinternet of things trend has led to various devices like gas meters,cars, and other devices to use internet connectivity. Developing andmanaging such connectivity devices can be complicated and expensive. Insome cases, an individual will have to establish a new long-termcontract with a telecomm provider to activate usage. This is not onlycumbersome but can be impractical for some applications where the datausage is very low. There are numerous barriers that act as hurdles fordevelopers and companies. Thus, there is a need in the communicationfield to create a new and useful system and method for programmaticdevice connectivity. This invention provides such a new and usefulsystem and method.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic representation of a system of a preferredembodiment;

FIG. 2 is an exemplary representation of an API response to a request toa device usage resource;

FIG. 3 is a flowchart representation of a method of a preferredembodiment;

FIG. 4 is a flowchart representation of processes of provisioning aconnectivity device;

FIG. 5 is an exemplary representation of an API response to a request toa device resource;

FIG. 6 is an exemplary representation of enabled capabilities of aconnectivity plan resource;

FIG. 7 is an exemplary representation of usage limits of a connectivityplan resource;

FIG. 8 is an exemplary communication flow diagram for activating aconnectivity device;

FIG. 9 is an exemplary communication flow diagram of offeringprogrammable communications using a callback URI;

FIG. 10 is an exemplary communication flow diagram of forwardingcommunications to an outside service; and

FIG. 11 is an exemplary communication flow diagram for deactivating aconnectivity device.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of preferred embodiments of the invention isnot intended to limit the invention to these preferred embodiments, butrather to enable any person skilled in the art to make and use thisinvention.

1. Overview

A method and system for programmatic device connectivity functions toenable connected devices to be programmatically controlled, monitored,and/or otherwise managed. The method and system preferably enable aprogrammatic approach to managing cellular-connected IoT (Internet ofThings) devices, phones, tablets, and other computing devices, andenabling the ability to program each call, text, and/or data packet. Themethod and system are preferably implemented in connection withdistributed SIM cards (i.e. subscriber identity module cards) thatoperate with one or more mobile cores used in providing data, SMS/MMSmessaging, voice, and other communication channels. The SIM cards arepreferably programmatically managed from a communication platform, whichmay enable various administrative interfaces including an administratordashboard and/or programmatic interfaces. Programmatic interfaces caninclude an API, application logic processing routines, callback events,and/or other suitable programmatic interfaces.

The system and method are preferably implemented by a communicationplatform. The communication platform is preferably a multi-tenantplatform where users are managers of different implementations using theprogrammatic cellular connectivity capabilities of the system andmethod. In one variation, the communication platform is an independentcomputing platform that provides functionality in cooperation with acellular network. In another variation, the communication platform is acomponent of a cellular network system.

As one potential benefit, the system and method may enable simplifiedmanagement of device connectivity. The system and method offer remoteprovisioning and ordering of SIM cards. This can be particularlyapplicable when managing multiple devices. In one application, abusiness may utilize the communication platform of the system and methodto manage a fleet of worker phones. The business could controlactivation/deactivation of worker-used phones, define customfunctionality, programmatically augment functionality, and/or collectdata on usage. In another application, a deployment of IoT devices coulduse a communication platform's implementation of the system and methodfor a unified data plan for the IoT devices that simplifies thedeployment, addition of devices, and/or billing.

As another potential benefit, the system and method can facilitateoffering a programmable mobile network, wherein various processes of acommunication network can be programmatically controlled and customized.Where traditional wireless customers are limited to standard features ofa carrier, a programmable wireless network could offer opportunities forany entity to build custom rules and features that are enabled withintheir network. Additionally such customization can be compatible out ofnetwork. While a phone number may or may not be associated with a SIMcard connectivity device, the origin phone number during outbound callscould be dynamically set through the communication platform.Additionally, the routing of communications to a destination addresscould additionally be dynamically set. In one example, a business coulduse this to setup customized internal routing options for a fleet ofworkers. For example, the system and method could provide an easyapproach to setting up custom phone numbers that when dials are routedto different departments. For example, a company could configure animplementation where dialing one directs the caller to one department,and dialing two to another department. Furthermore, these customizedrouting rules can be customized per SIM card.

As another potential benefit, the system and method may enable a commandcommunication channel that can be utilized for machine-to-machinecommunications. The command communication channel can be useful for IoTand other device applications.

The method and system can be applied to a variety of use cases.Generally, the system and method is implemented in a multitenantplatform that serves multiple entities. Through the platform, thevarious entities may apply the method and system to their own particularuse cases.

In one exemplary use of the system and method, a business may want toprovide its employees with company managed phones. SIM cards can beprovisioned for all employees through the system and method. Dependingon the needs of the business, different features may be enabled.

In one implementation, the system and method can be used in monitoringusage. In another implementation, the system and method could be used tosimulate a virtual carrier. The connected devices can be set to appearto be connected to the business's own carrier, wherein the actualcarrier is transparent to the end user.

In another implementation, the system and method can be used forremotely activating, suspending, and/or deactivating devices. This canbe useful with a dynamic work force where people join and leave.

In another implementation, the system and method could be used forautomatically encrypting all communications or communications matchingparticular properties (e.g., communications between employees or withcustomers). The programmatic capabilities can detect messages and/orcommunications satisfying some condition, and the message orcommunication could be encrypted or otherwise converted.

In another implementation, the system and method could be used to setcustom data or communication rules. For example, particular endpointsmay be whitelisted or blacklisted for a device. Similarly, some websitesand/or network-accessed services can be blocked for internet datacommunications.

In another implementation, the system and method could be used to buildcustom features such as changing what phone number is associated with adevice based on various conditions such as the location of the device orthe time of day. The phone number used to call a worker may change basedon location, which may be useful for contextually making a workeravailable.

In another implementation, the system and method could be used to bridgedifferent communication channels. For example, an SMS sent to a fellowemployee may be converted to an IP message using a private IP messagingchannel of the business.

While the system and method can be used for more traditional phonecommunication use cases, the system and method could additionally bebeneficial to alternative device communication challenges such asbuilding an internet of things device. SIM cards could be provisionedfor a set of different computing devices. In one aspect, the system andmethod can make provisioning of a SIM card for a device astraightforward procedure for a developer or manufacturer. The systemand method can be used to enable simple distribution of IoT devicesbecause of a streamlined provisioning process. The developer ormanufacturer of the IoT product can provision a SIM for a device. Then,when a customer or the IoT device is ready to be used, the SIM cardcould be activated with a data usage plan set by the customer or thedeveloper. The developer and the customer can be alleviated ofcontacting a carrier and setting up a new carrier subscription. Thesystem and method can additionally enable highly customizable usageplans. Some IoT products use very little data, and a data plan could beassigned to that device accordingly through the system and method.

The system and method could alternatively be used for other use cases.The examples described herein are to provide illustrative scenarios thatleverage some possible capabilities of different implementations of thesystem and method.

2. System for Programmatic Device Connectivity

As shown in FIG. 1, a system for programmatic device connectivity caninclude a communication platform 110, at least one connectivity device120, and a mobile core 130.

The communication platform 110 is preferably a multitenant serviceplatform. The communication platform 110 can enable multiple distinctaccounts, sub-accounts, or other entities to utilize the platformindependently. Generally, the accounts using the communication platform110 will be implementing some functionality that will serve a pluralityof end users. For example, a business may create an account within thecommunication platform 110 so that they can use the programmable deviceconnectivity features as an IT solution for the employees of thecompany. In another example, an IoT device company may use thecommunication platform 110 to provide the connectivity to their devices.In a preferred implementation, the communication platform 110 canfacilitate a set of communication capabilities such as PSTN calls,IP/SIP based voice or video calls, SMS or MMS messaging, IP messaging,third party communication channel integrations, notifications, internetdata communications, and/or other communication operations. Thecommunication platform 110 can include an API service 112, an eventcallback system 114, and/or application logic processing system 116.

The API service 112 functions as a programmatic interface for managingand interacting with configuration and operational management ofconnectivity devices. The API service 112 is preferably a RESTful APIbut may alternatively be any suitable API such as SOAP or customprotocol. The RESTful API works according to an application layerrequest and response model. An application layer request and responsemodel may use an HTTP-based protocol (HTTP or HTTPS), SPDY, or anysuitable application layer protocol. Herein, HTTP may be used, butshould not be interpreted as being limited to the HTTP protocol. HTTPrequests (or any suitable request communication) to the communicationplatform no preferably observe the principles of a RESTful design.RESTful is understood in this document to describe a RepresentationalState Transfer architecture as is known in the art. The RESTful HTTPrequests are preferably stateless, thus each message communicatedcontains all necessary information for processing the request andgenerating a response. The API service 112 can include variousresources, which act as API endpoints that can act as a mechanism forspecifying requested information or requesting particular actions. Theresources can be expressed as URI's or resource paths. In one exemplaryinstance, a GET request (or other suitable method of an applicationlayer protocol request) can be transmitted to a URI specifying aparticular API resource. The response to the request can includeproperties of the specified resource. In another exemplary instance, aPOST request (or other suitable method of an application layer request)can be transmitted to a URI specifying a particular resource. Propertiesof that request can initialize some action and/or change in data withinthe communication platform. Different resources can expose differentchannels to information and/or control of the communication platform andthe managed connectivity devices. In one variation, the API service 112can expose a device resource, device usage resource, a connectivity planresource, a commands resource, and/or other resources used inprogrammatically managing and interacting with connectivity devices 120.

The device resource functions to represent a physical connectivitydevice capable of connecting to a wireless network. As described below,a physical connectivity device is preferably a SIM card used by acomputing device in authenticating with a cellular network. Anindividual device resource is preferably created for each connectivitydevice 120. A device resource can have a number of properties that canbe set and used to augment operation of an associated connectivitydevice.

The device resource will preferably include various identifyingproperties such as a unique identifier and/or a friendly name.

The device resource can additionally include a status property. Thestatus property can indicate the current operating state of theassociated connectivity device. The status will impact capabilities andmetering of the connectivity device. In one variation, the differentpossible statuses can include “new”, “ready”, “active”, “suspended”,“deactivated”, “canceled”, “scheduled”, and/or “updating”. Otherstatuses could alternatively be used.

During a ‘new’ status, the connectivity device is waiting to beactivated so that it can join the network. A connectivity device couldexist in new status indefinitely at no charge. After transitioning toread or active, the connectivity status can preferably not return tonew.

During a ‘ready’ status, the connectivity device can connect to thenetwork and is capable of consuming network resources in accordance withits connectivity plan, but no monthly fee will be charged. Once theconnectivity device has consumed some threshold of data (e.g., 250 KB ofdata) and/or some time window has passed (e.g., three months), theconnectivity device can be transitioned automatically to active status.In one exemplary use case, a connectivity device could be set to a readystatus when a manufacturer is shipping their product using connectivitydevice to a customer if the manufacturer is not sure when the devicewill begin active use.

During an ‘active’ status, the connectivity device can connect to thenetwork and is preferably capable of consuming network resources inaccordance with its connectivity plan.

During a ‘suspended’ status, the connectivity device can be blocked fromconnecting to the network.

During a ‘deactivated’ status, the connectivity device can be blockedfrom connecting to the network. After some time window (e.g., 72 hours),the connectivity device can be transitioned automatically to theterminal status canceled. This status can be used when a customer neverwants the connectivity device to reconnect (for example a phone or IoTdevice has been lost or stolen).

A ‘canceled’ status can be a terminal status, and the connectivitydevice can be blocked from connecting to the network and can no longerbe reactivated.

During a ‘scheduled’ status, an upstream network operator may betemporarily unable to update the status of this connectivity device.During this state, the connectivity device status will preferably beautomatically updated to the requested status when the upstream networkoperator resumes accepting transactions.

During an ‘updating’ status, the connectivity device is in the processof being asynchronously updated. While the connectivity device isupdating, it may not be possible to modify some fields. A statuscallback URI can be used during changes in status.

Some of the statuses will be read only, but some may be set or requestedprogrammatically. Setting the status property of a device resource canbe used as a mechanism for requesting a transition of the connectivitydevice to a new status. Exemplary mutable statuses can include the“ready”, “active”, “suspended”, and “deactivated” statuses. Accordingly,the device resource can be used for activating, suspending, ordeactivating a connectivity device through an API request to theappropriate device resource.

The device resource can additionally include a connectivity planreference which functions to set a connectivity plan for theconnectivity device. The connectivity plan reference is preferably aunique identifier of a connectivity plan resource.

The device resource can additionally include callback references thatfunction to define actions or functionality that is invoked on differentevents. The callback references are preferably used in connection withthe event callback system 114. The callback references are morepreferably callback URIs (Universal Resource Identifier) such as a URL(Universal Resource Locator) to a webserver hosting application logic.There can be different types of callback references for differentaspects of the connectivity device. Preferably, there is one that can beset for each mode of communication such as voice, messaging, and data.Different callback references may additionally be set for incomingversus outgoing or other suitable aspects of connectivity. There couldbe a voice callback URI, a messaging callback URI, a data callback URI,a command callback URI, and the like. The voice callback URI can be usedfor PSTN, SIP, or other forms of synchronous communications. Themessaging callback URI can be for SMS, MMS, and/or IP messages.Additionally there could be a status callback URI that is used duringchanges in status of the connectivity device. A callback method propertycould additionally be set for each callback URI so that applicationlayer protocol communications can use appropriate methods. For example,when using an HTTP-based protocol (e.g., HTTP/HTTPS), GET or POST can bespecified for each callback reference.

The device usage resource can be used to programmatically access usageof the connectivity device as shown in the exemplary device usageresource of FIG. 2.

The connectivity plan resource functions to at least partially specifyoperational capabilities and permissions and also the metering andbilling options of the connectivity device. The connectivity plan caninclude various properties that can be used to set capabilities of theconnectivity devices. Capabilities such as data communications, SMSmessages, MMS messages, PSTN calls, national roaming, internationalroaming and other capabilities could be enabled, disabled,capped/limited, and/or otherwise controlled. As one additional property,a billing mode could be set through the connectivity plan resource. Abilling mode can set different ways in which connectivity devices aremetered and/or billed. In a pooled billing mode all the usage of aconnectivity devices associated with the connectivity plan are summed(i.e., pooled) when billing, evaluating progress against pricing tiers,evaluating usage limits, and/or assessing usage. In an individualbilling mode, usage of connectivity devices associated with theconnectivity plan are treated individually.

Alternative architectures of programmatic resources could alternativelybe used. As an exemplary alternative, the connectivity plan could bedirectly specified within the device resource. As another exemplaryalternative, the callback references and capabilities could be specifiedin the connectivity plan resource.

The API service 112 may additionally include a commands resource thatcan be used to create and access machine-to-machine communications. Acommand resource can be used for sending a data message to theconnectivity device. In one implementation, message content can betransmitted through an SMS protocol. However, any suitable medium ofcommunication or protocol could be used. The command resource can beused in delivering inbound communications. Outbound messages could behandled differently. As mentioned above, a device resource could specifya command callback, which would make an asynchronous application layerrequest to the command callback URI with outbound command or messagecommunications.

The event callback system 114 can function to enable event triggers orwebhooks to be activated in response to different state changes orevents. Event callbacks may be triggered at particular stages of acommunication. When an event callback condition is satisfied, aconfigured event is executed. The event could be an internal operation,a callback event, or any suitable action. An internal operation can be aclosed action that may not be fully exposed to an account holder. A URIcallback event preferably includes making an application layer protocolcommunication to an external resource located at the specified URI. Acallback event may alternatively be configured by account for anysuitable event such as when a connectivity device 120 is activated, whena communication associated with a device is received, or any suitablecondition. Callback URIs may be setup to retrieve application logic tosynchronously manage a communication.

The application logic processing system 116 may enable business logic tobe defined through an executable document. Preferably, application logicis specified through a structured document. In one variation, a markuplanguage document can be used in specifying a set of instructions andconditions that can be sequentially executed. The application logic maybe retrieved from a remote server. For example, the event callbacksystem 114 may retrieve application logic from a URI, which is thenprocessed in association with a conversation. Application logic mayalternatively be stored within the communication platform 110.

The connectivity device 120 functions as a connectivity destination orendpoint for communications. In a preferred implementation, theconnectivity device of the system can be a SIM card or subscriberidentity module card. The SIM card when used with a telecommunicationsmodule can authenticate a device as a subscriber and participant on anetwork. The connectivity device can be a SIM card, as one knowledgeablein the art would understand. The SIM card could include a unique serialnumber (e.g., integrated circuit card identifier (ICCID)), internationalmobile subscriber identity (IMSI) number, and/or other information suchas service access credentials, PIN numbers, and the like. In oneimplementation, SIM cards can be distributed in combination withactivation codes, wherein the activation codes can be communicated withthe communication platform and used by the communication platform foraltering the status of the connectivity devices. In other variations,the connectivity devices could be other types of devices such as phones,tablets, or other suitable devices. Such devices will preferably includea SIM card, integrated SIM data, or otherwise be capable of connectingto a network.

A mobile core 130 is the set of network infrastructure used infacilitating communications with the device. In one implementation, anetwork carrier with the mobile core 130 could be implementers of thesystem and can integrated the mobile core 130 with the communicationplatform. In an alternative implementation, the mobile core 130 can beenabled through an outside partner, and the system could include amobile core 130 interface such that the communication platform 110 caninterface with an outside mobile core 130. For example, thecommunication platform may interface with multiple carrier networks,where the devices have communications using the carrier networks as atleast an intermediary resource for communications. Communications arepreferably routed through the communication platform for at least asubset of communication types.

3. Method for Programmatic Device Connectivity

As shown in FIG. 3, a method for programmatic device connectivity of apreferred embodiment can include provisioning a connectivity deviceS110, servicing communications of the connectivity device S120, andprogrammatically managing the connectivity device S130. The methodpreferably functions to enable connectivity devices to be activated,deactivated, and/or otherwise managed. Additionally, the management ofthe connectivity devices can be facilitated through an interface of acommunication platform and, more preferably, a programmatic interfacesuch as an API. The programmatic interfaces could be used in augmentingcommunications of the connectivity device. By exposing a programmaticinterface to the management of connectivity devices, services andapplications can provided automated management of cellular connectivityof one or more devices. The connectivity devices are preferably SIMcards or SIM-enabled devices that use a SIM card in enablingconnectivity to a cellular network. The method is preferably implementedby a system such as the one described above, but any suitable system mayalternatively be used.

The method can be particularly applicable to managing a plurality ofconnectivity devices, wherein provisioning servicing, and managing areapplied across multiple connectivity devices. Subsets of the multipleconnectivity devices could be individually configured with distinctconnectivity plans and customized functionality. The method couldsimilarly be applied to a single connectivity device.

Block S110, which includes provisioning a connectivity device, functionsto enroll and setup data connectivity for a device. A connectivitydevice is preferably provisioned with an account of a communicationplatform. The communication platform can be one as described above andis preferably a multitenant communication platform such that distinctentities could independently provision connectivity devices through thecommunication platform. A connectivity device is preferably any devicewith capability to authenticate with a telecommunications network andparticipate as a subscribed entity. More specifically, provisioning aconnectivity device can include provisioning a SIM card. A SIM card canenable identification of a computing device connecting to a network, andcommunications described in the method can be SIM card originatedcommunications. In SIM card originated communications, the computingdevice transmitting and receiving telecommunication signals isidentified as an endpoint as prescribed by the SIM card. In alternativeimplementations, the connectivity devices can be computing devices withincluded SIM cards or have digital equivalent of a SIM card. Forexample, a connectivity device may not have a removable SIM card buthave identifiers and set within software or hardware of the device.

In one variation, provisioning can include providing connectivitydevices, wherein the operator of the method can manage a known supply ofconnectivity devices. In providing connectivity devices, thecommunication platform can have a set of pre-registered connect devices(e.g., SIM cards) with known identifiers. In one implementation, a setof SIM cards can be issued by a carrier network to the communicationplatform, wherein the issued SIM cards are managed by the mobile core ofthe carrier network in a way compatible with the method. In thisvariation, only SIM cards provided by the communication platform arecapable of operation with the method. Alternatively or additionally,ad-hoc registration of connectivity devices can enable outsideconnectivity devices to be migrated and enrolled for use with themethod.

Providing connectivity devices can additionally relate to the physicaltransfer of the connectivity devices to an account holder. In onevariation, the communication platform or other outlets could sell theconnectivity devices. In another variation, the communication platformcould expose a programmatic provisioning API that enables ordering ofSIM cards. For example, an API can be exposed enabling an entity toorder new SIM cards programmatically. An API request could specify thenumber, the SIM card type, and an address for SIM card delivery. In onevariation, the SIM cards can arrive ready for use. Alternatively, a SIMcard may be provisioned once the user has the SIM card in hand. This maybe used to onboard SIM cards that a user already possesses.

Provisioning a connectivity device preferably includes uniquelyassociating network operating identifiers of the connectivity devicewith a corresponding programmatic device resource S122, settingcommunication metering properties in a programmatic connectivity planresource S124; and activating network communication status of theconnectivity device S126 as shown in FIG. 4. The processes of blocksS122, S124, and S126 function to setup a connectivity device andtransition the connectivity device to an active state wherecommunication and metering can be executed. The connectivity planresource and the device resource are preferably programmatic resourcesexposed through an API of the communication platform. Setting andaugmenting of programmatic resources can preferably be facilitatedthrough block S130. Additionally, as with block S130, programmaticresources may additionally be set or changed through any suitableinterface such as a user interface exposed on a control portal on awebsite or application of the communication platform.

Block S122, which includes uniquely associating network operatingidentifiers of the connectivity device with a corresponding programmaticdevice resource, functions to setup endpoint access and link identity ofa connectivity device with an account. The device resource, along withother associated resources, can define state and settings of anassociated connectivity device as shown in an exemplary API informationrequest of FIG. 5. Preferably, the network operating identifier is oneof a SIM card. The identifier for a SIM card could be an integratedcircuit card identifier (ICCID). The international mobile subscriberidentity (IMSI) and/or other network identifier may additionally oralternatively be associated with the device resource. In somevariations, the SIM card can be associated with a phone number, whichcould additionally be associated with the device resource. In othervariations, the phone number addressing can be provided through thecommunication platform. In this variation, a human facing endpointaddress such as the phone number for the connectivity device can be setwithin the communication platform, wherein the actual device endpointaddress can be transparent or a minor detail to the end user. The actualdevice endpoint address can be used internally, but a level ofindirection is introduced so that a phone number is used to referencethe device outside of the platform and mobile core, which functions tomake device management more flexible. For example, the phone number usedto access a device can be set and updated in real-time in block S130.

Block S124, which includes setting communication metering properties ina programmatic connectivity plan resource, functions to configurebilling and/or usage limits for communications from connectivitydevices. Preferably, the connectivity plan is abstracted away to its ownprogrammatic resource in the communication platform. As discussed, thecommunication metering properties could additionally be properties of adevice resource or represented in any suitable manner. In one variation,connectivity plan resources can be generated and then associated with anumber of device resources. The act of associating a connectivity planresource with a device resource, in one variation, can initialize orenable activation of the connectivity device. Prior to a device resourcehaving a connectivity plan, the device is preferably restricted fromactivating.

The communication metering properties preferably relate to eachavailable communication medium such as data usage, datamachine-to-machine transmissions, SMS messages, MMS messages, PSTN voicecalls, and/or other forms of communication. Additionally, theconnectivity plan resource can define enabled capabilities and/or usagelimits. Limits can relate to caps, tiered billing, rate limiting, and/orother forms of communication limits. Preferably, the metering propertieswill define the options used in measuring usage and generating a billbased on the measured usage. Setting communication metering propertiesin a programmatic connectivity plan resource can include settingcommunication metering modes, communication capabilities, communicationlimits, and/or other properties. These different properties may impactbilling rates. Alternatively, billing rate properties can additionallybe exposed for being defined.

The connectivity plan resource can expose different communicationmetering modes. The metering modes could be set by selecting from a setof offered metering modes such as a pooled mode and an individual mode.In a pooled mode, a usage from a set of devices can be measured andbilled as a group. A pooled mode may be beneficial when there are alarge number of devices, but each uses a small amount of data. In anindividual mode, usage is measured on a per-device basis.

The connectivity plan may additionally include communication capabilityproperties. A capability property can describe the network resourcesthat a device is permitted to consume if they are available. Forexample, if a device is technically capable of roaming onto aninternational partner network, the capabilities property can definewhether this is allowed and for which channels it is allowed. Thecapability property can include a set of different channels such asdata, voice, messaging, commands, and/or other capabilities.Additionally each capability can be scoped to different areas of usage,which can include home usage, national-roaming, andinternational-roaming. Home scope enables connectivity on the homecarrier network. National-roaming can enable roaming for carriernetworks in the same country region. International-roaming can enableconnecting through other carrier networks internationally. As oneexample shown in FIG. 6, a device may be permitted to roam usingmultiple channels on international networks but not other domesticnetworks, and the device may be prohibited from makingmachine-to-machine commands by defining a null command channel.

The connectivity plan may additionally include communication limits,which functions to enable restrictions to be placed on the volume ofnetwork resources consumed by the device. In one variation, a capcommunication limit can be used to set an upper limit of usage. In a caplimit, an optional cap period may be used to automatically renew a cap.Caps can be placed for different channels such that voice, messaging,commands, and data may be individually limited. In one example shown inFIG. 7, a user may set a cap to limit a device to 50 MB of data and 30minutes of voice calling per day, while allowing unlimited SMS messagingand commands. A cap property could additionally be used in settingfinite, non-renewing usage limits. For, example, a device could be setso that it could only consume 2 GB of data over it's lifetime unless anew connectivity plan is created or if the device is deactivated andreactivated.

Block S126, which includes activating network communication status ofthe connectivity device, functions to enable a connectivity device foruse with a network. Activating a connectivity device preferably involvessome event that triggers transitioning a connectivity device from itscurrent non-active state (e.g., a ready status, suspended status, etc.)to an active state. As shown in the exemplary scenario of FIG. 8,activating network communication status of the connectivity device caninclude receiving a programmatic request to activate the connectivitydevice and initiating activation of the connectivity device on thenetwork. Activation on the network can take some amount of time that mayprevent a readily available response to the activation request.Accordingly, the programmatic activation request can include a callbackURI and/or a callback URI can be associated with connectivity device.For example, a status callback URI can be a property of the deviceresource. With a callback URI established, then activating the networkcommunication status can additionally include transmitting anasynchronous status update on activation of the connectivity device tothe status callback URI. The status callback URI can similarly be usedfor any status changes of a connectivity device. Preferably, an accountwill set the status callback URI to a managed URI such that a webserverof the account holder can detect status changes and take any appropriateactions.

Provisioning of the connectivity device will preferably include someregistration process for associating a connectivity device and anaccount. In the variation, where the connectivity devices are providedby the communication platform, the network identifiers used forinstructing a mobile core of how to interact with the connectivitydevices can be established in the communication platform. A registrationprocess can be used to map a convenient device identifier with theunderlying identifier. Alternatively, the various network identifiersmay be entered manually or looked up using some alternative mechanism.

In one variation, connectivity devices can be registered through adevice identifier that accompanies a physical connectivity device. Forexample, a SIM card can be provided along with a uniquely associatedactivation code. The activation code can be used in registering and/oractivating the SIM card. In this variation, provisioning theconnectivity device can include providing SIM cards, where each SIM cardis uniquely associated with a provided activation code; and receiving aregistration request with a user-supplied activation code and generatingthe device resource. In this variation, the device resourcecharacterizes configuration of the connectivity device identifiedthrough the user-supplied activation code. The network operatingidentifiers of the connectivity device can be searching for aconnectivity device record with an associated activation code thatcorresponds to the user-supplied activation code. Setting of aconnectivity plan resource and final activation can be completed oncethe connectivity device is registered with the account.

In another variation, connectivity devices can be preemptivelyassociated with an account prior to the account holder having physicalaccess to the connectivity devices. This can be used such thatconnectivity devices can be pre-registered and ready for activation uponreceipt of the connectivity devices. This could be useful when anaccount holder has a use case where large volumes of connectivitydevices will be used. This variation can include receiving an order fora connectivity device from the account of the communication platform,and, in association with fulfillment of the order of the connectivitydevices, generating device resource accessible through a programmaticinterface of the communication platform. Fulfillment of the order of theconnectivity devices can mean the device resources are generated afterconfirming the order, during processing of the order, during shipment ofthe connectivity device, or at any point. In one variation, aplaceholder device resource can be created immediately following anorder of the connectivity device. Network operating identifiers could beassociated with the device resource through registration facilitated bymethod operators. For example, the registration can be completed by thecommunication platform or a partner of the communication platform priorto shipment of the connectivity device. Alternatively, a device resourcecould be created after registration by the method operators. Bypre-registering a connectivity device, an account holder could obtainfaster access for configuring the connectivity devices for use. Forexample, once a device resource is established for the account, theaccount holder could begin setting a connectivity plan, requestingactivation, or setting any operating properties of the device.Pre-registration can additionally lock the connectivity devices to useby that account, such that one would need access to the account toactivate and/or use the connectivity devices.

As will be described below, the device resource and/or the connectivityplan resource can expose various operational options which can be usedfor introducing programmatic control of communications, customcommunication rules like routing, and/or other features. These will bedescribed in more detail in reference to block S130.

Block S120, which includes servicing communications of the connectivitydevice, functions to enable usage of the device. A mobile core ispreferably used to facilitate the capabilities of a device. The SIM cardis preferably used by a computing device such as a smart phone,computer, IoT device, or other suitable device in establishing networkconnection and sending/receiving communication. The device may be usedfor data downloading and uploading over the internet, SMS messaging, MMSmessaging, IP messaging, voice calls, video calls, and/or other suitablechannels of usage. Outbound and inbound communications can be made.Servicing communications preferably includes metering and measuringusage of the connectivity device. Metering can include measuring datausage, counting communications, counting time of synchronouscommunications, and/or creating a record of any suitable metric that maybe used in limiting and/or billing of the usage.

In one variation, the communication platform can facilitate exposingprogrammable communications when servicing communications. Exposingprogrammable communications can enable application logic to be appliedin connection with one or more channels of communication. Acommunication can be synchronously processed according to associatedapplication logic. Synchronous application logic can enable acommunication to be controlled in real-time. For example, a call couldbe rerouted automatically or a message could be translated before beingsent to a destination. Communication can alternatively be asynchronouslyprocessed, wherein application logic is executed outside of thecommunication flow. For example, a developer may want to receive anotification each time an outgoing communication is made from the deviceso asynchronous application logic could be implemented to notify anapplication server of the developer without blocking or stalling theoutgoing communication.

Programmable communication can involve setting a callback URI for aconnectivity device. Callback URIs are preferably properties ofassociated device resources. There could be distinct callback URIs fordifferent channels of communication such as a data command callback URI,a SMS/MMS callback URI, a voice callback URI, and/or any suitable typeof callback URI. Fallback callback URIs could additionally beconfigured. At different events the callback URI is processed and usedto retrieve application logic. The application logic can then beprocessed. A callback may be a synchronous callback or an asynchronouscallback.

When accessing a callback URI, an application layer protocol can be usedin a request response model to retrieve media that specifies actions tobe taken within the communication platform as shown in FIG. 9. Anapplication layer protocol is preferably an HTTP-based protocol likeHTTP or HTTPS, but may alternatively be SPDY or any suitable protocol.An application layer request can be made to the configured callback URI.That callback URI will generally direct the request to a servercontrolled by the entity managing the device, and will perform anysuitable processing task to determine the response. Communicationattributes are preferably sent with the application layer request suchthat an application server processing the application layer request cangenerate a dynamic response. The communication attributes can includethe connectivity device identifier, a communication destinationidentifier (e.g., the endpoint the communication was directed to by thedevice), communication type, communication payload, and/or any suitableproperties. Then a response message is received at the communicationplatform. The response message can include a document with a set ofinstructions that can be sequentially processed and executed by theplatform. The response message may alternatively include media, whichmay be used in the communication. Callback URIs can be used for outboundcommunications that originate from the connectivity device. Instances ofoutbound communications can include receiving a communicationoriginating from the connectivity device at the communication platform;transmitting an application layer protocol transmission to theconfigured callback URI of the device resource; and receiving a responsewith application logic; and processing message according to theapplication logic. Communication attributes such as communicationdestination can be communicated in the application layer protocoltransmission such that the server handling the callback URI can use theattributes in generating dynamic application logic. Inboundcommunications to the connectivity device or to an endpoint mapped tothe connectivity device can similarly include receiving a communicationfrom an external communication, the communication directed to anendpoint associated with a device resource within the communicationplatform; transmitting an application layer protocol transmission to acommunication callback URI of the device resource; receiving a responsewith application logic; and processing the communication according tothe application logic. The application logic can include variouscapabilities such as communication routing instructions, playing mediafiles, performing text-to-speech, recording communications, establishingconferences, setting up a call waiting, receiving user input or othersuitable functionality.

Other mechanisms for programmable communications may additionally oralternatively be used. In one variation, communication routing rulescould be configured and associated with a device resource such thatoutbound and/or inbound communications could be dynamically modified inaccordance with the routing rules. Servicing a communication candirecting communications according to communication routingconfiguration of the device resource. These routing rules could beprogrammatically configured through an API or set in a user interface ofan account accessed control portal. For example, a mapping ofdestination endpoints could be used for associating device-provideddestination endpoints with executed endpoints. In this way, outboundcommunications from a device can be automatically mapped to a setdestination. This could be used in preventing outbound communicationswith particular endpoints. The destination endpoint mapping couldadditionally include mapping destination endpoints to origin endpointsthat are to be used when contacting a destination endpoint. The originendpoints are preferably endpoints allocated to the account for usage.In one exemplary use case, a user could dial different phone numbers ona phone and the method could automatically direct communications todifferent phone numbers and automatically simulate the communicationsfrom originating from a dynamically selected phone number. In oneexample, a business could easily enable company-wide shortcodes forcompany managed devices. The short codes could be customized perconnectivity device. For example, each customer could be enabled to dial‘1’ to reach their manager, ‘2’ for their regional HR representative,‘3’ for regional IT support, and the like.

Routing rules could similarly be used for incoming calls. This can beparticularly useful when a number of connectivity devices are beingmanaged through the method. Inbound communications could be dynamicallyrouted to appropriate connectivity devices.

The routing rule functionality could additionally or alternatively beimplemented through application logic processing using the callback URImechanism described above. An application server at a communicationcallback URI could render a response such as the one shown in FIG. 9,where the routing of the communication and/or mutation of thecommunication can be affected in any suitable manner. Highly customizedlogic could be used within the application server in determining thedestination endpoint, the origin endpoint, and/or any otherfunctionality in the application logic.

In a related variation to routing rules, the method could enable adevice resource to be configured with communication-to-service routing,which can function to enable communications, in particular datamessages, to be directly forwarded to an external host.Communication-to-service routing can be used in forwardingcommunications to an external database, data warehousing system, a cloudhosted data storage solution, and/or any suitable destination. This canbe particularly applicable when the method is used by an account holderin managing connectivity of IoT devices. The IoT devices could be partof a sensor network using the network as a transport. This variationcould be used in uploading data from the IoT devices to a particulardestination. A communication-to-service routing variation can include:configuring credentials of an outside data destination service;receiving a data message originating from the connectivity device at thecommunication platform; and transmitting the data message to theconfigured data destination service using the configured credentials asshown in FIG. 10.

The method can additionally include enforcing policy when servicingcommunications. Enforcing policy can involve metering and billing forusage of a device. Devices are preferably metered according to theconnectivity plan for the device. At the end of a billing period, a billcan be calculated and issued for the metered usage of one or moredevices. Enforcing policy can additionally be used in restricting usageof the connectivity device. During new activity, the metered usage ofthe device (or device pool) can be compared to the caps in theconnectivity plan to determine if the activity is permitted.

Block S130, which includes programmatically managing the connectivitydevice, functions to enable remote configuration of the connectivitydevice through an interface that can be integrated with otherapplications or services. The device resource and/or connectivity planresource can be two programmatically-accessible resources through whichoperation and network connection of a connectivity device can bemanaged. As described above, callback URIs and application logicprocessing can be set through the device resource and/or connectivityplan resources to programmatically control or interact withcommunications. Preferably, properties of API resources such as thedevice resource and the connectivity plan resource can be read and/orupdated to trigger changes. Additionally, a communication resource suchas a command resource can be used for programmatically triggeringcommunications originating and/or terminating at the connectivitydevice.

Additionally, the various configuration and activity of a connectivitydevice can be exposed through an interface. The interface can be agraphical user interface (e.g., a dashboard), wherein an administratorcould review activity and make changes through a user interface.Alternatively or additionally, an API can be exposed and morespecifically a REST API. Through API resources are preferably used toalter management of associated connectivity devices. An account holdercould remotely augment the addressing of a connectivity device. Forexample, one or more endpoint may be routed to the connectivity device.The change in routing can be made in under a minute and may be changedmultiple times. An account holder could alter callback URIs to updatehow event callbacks are triggered. The connectivity plan could beremotely altered to change billing and/or permissions.

The method may expose an interface for changing operating status of aconnectivity device. This could be used to register, activate, suspend,deactivate, or set any suitable operating state. Registering preferablytransitions a connectivity device to a ready state. Status changes canbe set by an account holder through a user interface or a programmaticinterface. In a programmatic interface, an API request can be submittedto an appropriate resource (e.g., the device resource) with a statusproperty set to the newly desired status.

In one variation, activating a connectivity device can include receivinga programmatic request to activate a connectivity device and initiatingactivation of the connectivity device on the network as shown in FIG. 8.As discussed above, a status callback URI could be configured for adevice resource or otherwise specified in the request, whereinactivating a connectivity device can include transmitting anasynchronous status update on activation of the SIM card to the statuscallback URI. Once a connectivity device is activated, the device canconnect to the network and participate in communications. Additionally,metering and/or billing can be activated for the connectivity device. Insome cases, a status update may fail in which case the status callbackURI will receive a message indicating the update failure.

In a related variation, deactivating a connectivity device can includereceiving a programmatic request to deactivate a connectivity device anddeactivating the connectivity device on the network as shown in FIG. 11.Deactivation preferably prevents communication and/or reactivation ofthe device. Suspending a device could be a similar process wherein theconnectivity device could be reactivated.

During use of the connectivity device, the connectivity plan could bealtered. Altering the connectivity plan can include receiving aprogrammatic request changing a current connectivity plan resourceassociated to the device resource to an updated connectivity plan andmetering the connectivity device in accordance with the updatedconnectivity plan after changing the current connectivity plan. Aconnectivity plan could be changed by associating a new connectivityplan to the device resource. A connectivity plan could alternatively bechanged by updating an existing connectivity plan resource associatedwith the device resource. As above, this could be facilitated through auser interface or a programmatic interface. As discussed above, aconnectivity plan may enable changes to metering modes, enabledcapabilities, usage limits, and/or other usage aspects. For example, theconnectivity plan could specify a metering mode, an activation state ofvoice communication, an activation of message communication, anactivation state of data connectivity, and a data limit.

In one variation, the method can expose a command API resource that isutilized for machine-to-machine communications. A command using SMSpreferably issues commands in a text-based format and the content isarbitrary, wherein a developer can determine how the payload is used.Alternatively, MMS or alternative communication channels may be used tooffer alternative payload formats. Commands, data communications, and/orother forms of communication can be initiated through a user interfaceand/or programmatic interface. Use of a command resource can includereceiving a programmatic communication request to transmit data to aconnectivity device and processing message transmission to theconnectivity device. The communication request can specify the type ofcommunication and the contents of the communication. The communicationrequest can additionally include a status callback URI or the statuscallback URI may alternatively be specified in association with thedevice resource and/or connectivity plan. When a status callback URI ispresent transmission of a communication can additionally includetransmitting an asynchronous status update on completion of processingmessage transmission. Preferably, the asynchronous status update willindicate successful transmission, but may alternatively indicate anerror state or other outcomes of the attempted transmission.

The system and method of the preferred embodiment and variations thereofcan be embodied and/or implemented at least in part as a machineconfigured to receive a computer-readable medium storingcomputer-readable instructions. The instructions are preferably executedby computer-executable components preferably integrated with the mediaintelligence platform. The computer-readable medium can be stored on anysuitable computer-readable media such as RAMs, ROMs, flash memory,EEPROMs, optical devices (CD or DVD), hard drives, floppy drives, or anysuitable device. The computer-executable component is preferably ageneral or application specific processor, but any suitable dedicatedhardware or hardware/firmware combination device can alternatively oradditionally execute the instructions.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changescan be made to the preferred embodiments of the invention withoutdeparting from the scope of this invention defined in the followingclaims.

1. A method comprising: provisioning a first connectivity device and asecond connectivity device with an account of a communication platform,the first connectivity device associated with first communicationmetering properties and the second connectivity device associated withsecond communication metering properties; activating networkcommunication status of the first connectivity device and the secondconnectivity device, after which communications received from the firstconnectivity device are serviced by the communication platform accordingto the first communication metering properties, and communicationsreceived from the second connectivity device are serviced by thecommunication platform according to the second communication meteringproperties; receiving, from a computing device of an administrator ofthe account of the communication platform, a request to modify the firstcommunication metering properties, wherein the request is received viaan Application Programming Interface (API) exposed by the communicationplatform; and modifying the first communication metering propertiesbased on the request, yielding modified first communication meteringproperties, wherein modifying the first communication meteringproperties causes communications received from the first connectivitydevice to be serviced by the communication platform according to themodified first communication metering properties.